Subject: Nagi Swaminathan 3/7 comments on flow control

From: [email-masked]
Date: Wed, 9 Mar 94 23:34:04 EST

Nagi,
I read your suggestion about a receiver-controlled max window size
carefully because I think we need some creative brainstorming on this
"lack of feedback" problem.  I could not fully understand what you
proposed, however.  Could you give an example with some specific
counter values, and show just what variables are needed where?

My particular points of confusion were:
  Your max window size seems exactly the same as the NWS variable       soli-
  in my proposal.  Is that correct?  It sounds like you are saying      on may
  that the sender maintains its own "real" window below this value.     pon
  Is it the start of the "real" window that triggers PREQ?  If so,
  do we have a problem where the receiver consistently believes it
  is granting a window value larger than what the sender is using,
  and over time the difference between the two values keeps growing?

Offhand I don't think your ideas pose a patent issue, but as you can
see I don't really understand them yet.

As for what we could loosely call the "deadlock issue", you're right
that this keeps popping up.  I can think of buffering implementations
that make this a real concern and others that lessen the risks.  We
are exposed somewhat without an "out of band" pacing mechanism but
so far no one has shown we're broken in a general enough way to cause
a move to an "IPMs only on a separate TCP connection" rule.  If anyone
would like to make the case for this rule, now's certainly the time.

Peter